Internet networks and mobile communication networks, such as Global System for Mobile communications (GSM) and 3G, use gateway nodes to allow hosts to access communications networks, and server nodes to provide services to the host. Edge nodes such as Access and Service Edge nodes are frequently “pooled” in a network, to allow load sharing and balancing between pool members, along with increased availability and better utilization of resources. Conventionally, pools are either statically configured, and static pooling can also be based on the Domain Name System (DNS).
Statically configured pools are based on the concept of statically pre-configuring information about selectable edge nodes for a given service. Selection algorithms are used to select a suitable edge node for use by a host. Statically configured pools allow for better sharing of the load distribution between nodes having similar functionality, and simplified node dimensioning due to more accurate estimates of traffic over larger geographical areas.
Another type of statically configured pooling is DNS-based pooling. Rather than configuring pools in each node that may require this information, the configuration is performed in a DNS server. A host sends a DNS query to the DNS server, which returns a list of IP addresses identifying members of a pool. The host then selects one address from the list based on an internal selection algorithm.
A refinement of this idea is for the DNS server to introduce limited selection before sending the list of IP addresses to the MS. Examples of these are “sort lists” and “round robins”. A Sort List is a DNS feature where the order of addresses in the list of IP addresses are ordered based on the source address of the query. A Round Robin is a DNS feature to balance traffic between two or more addresses. Round Robin is used in General Packet Radio Services (GPRS) networks to distribute the load between multiple Gateway GPRS Support Nodes (GGSNs).
A disadvantage to using Sort Lists in the DNS server is that there is no guarantee that the original order will always be maintained as the information is passed from DNS server to DNS server. To ensure the correct order is maintained, Sort Lists must be configured in all the DNS servers in a network, adding considerable complexity to large DNS solutions. In some cases it may not be possible to set Sort Lists on all servers.
Round Robin operates using static information obtained from a DNS database. The status and actual load on a node are not taken into account when the DNS server responds to a request. Round Robin may override the structure of a response sent from an authoritative server or the effect of a Sort List.
DNS pooling also enables service-specific selection by using so-called “resource records” (RRs). In a basic DNS server described in IETF RFC 1034/1035, pools can be configured with multiple “address” RRs (A RRs) for a given host name. When the DNS server receives a request for a list of addresses, it returns all RRs matching the query, and the entity making the requests then selects an address from the list.
A more enhanced service-based pooling solution is specified in RFC 2782, which describes a SRV RR-enabled DNS server. Server pools are configured using multiple “service” resource records (SRV RRs) for a service. A RR format also includes PRIO and WEIGHT parameters. The DNS server's response to a request contains all possible choices of server with priority and weight info, allowing the MS to make a server selection on the basis of pre-defined rules based on the received priority and weight parameters.
A problem with static pooling is that the pools must be configured and updated at any node that may be affected by changes in the pooling. Pooling membership therefore requires a considerable amount of configuration work. For example, if a network is extended it may require a re-design of existing pools, and possibly the introduction of new members into pools. Re-configuration in affected nodes is therefore required not only to take account of newly introduced pool members, but also existing ones. Similarly, changes in the network topology require operator intervention.
A further problem with static and DNS-based pooling is that it cannot take account of changes in the network without being reconfigured. So, for example, static pooling cannot take account of current network conditions such as the current load on the transport network. The selection process may therefore lead to overload on some pool elements, whilst other pool elements are underutilized. As a consequence, QoS requirements for a given service cannot be guaranteed. Furthermore, the load on pool elements such as edge nodes cannot be taken into account for load sharing purposes. Other characteristics of the pool elements cannot be taken into account either. Such characteristics include connectivity to specific networks, supported services, and so all pool elements must be configured similarly and have all required features in order to avoid selecting a pool element that does not have the required features. Using static or DNS-based pooling, there is no or limited topology information available.
Static pooling makes configuration management of pools cumbersome. For example, in a scenario where less expensive, and therefore less reliable pool elements are used, network redundancy provided by pooling would allow for high network reliability. In this scenario, however, adding and removing pool elements to/from pools may become a frequent event, affecting configuration significantly.